Guardrails 可以理解成部署在 AI Application 周圍的安全控制機制，用來限制 AI 可以接受什麼、產生什麼，以及在什麼情況下可以執行某些行為，例如一個公司內部 AI Assistant 可能會設定不允許處理明顯的惡意輸入、不允許輸出 API Key 等敏感資訊、不允許一般員工執行管理員操作、高風險操作必須經過人工確認等，所以 Guardrails 並不是單純在 System Prompt 下指令，而是在 AI Application 的不同位置加入安全控制。

概念上可以想成 User Input -> 安全檢查 -> LLM -> 安全檢查 -> Tool / External System -> 權限與操作限制 -> Response，也就是所謂的 Defense in Depth（縱深防禦），即使其中一道防禦失效，後面還有其他機制可以降低影響。

其實經過上週的介紹也可以發現只靠 System Prompt 是不行的，很容易被攻擊者試出漏洞，所以我們才需要Guardrails 這種更嚴謹的作法，實際的 AI Application 通常也會在不同階段建立不同的 Guardrails，類似一種整體防禦的概念，不是特定工具，就可以在每個階段都審查一遍有沒有重大安全問題，而我們也要知道她當然不是百分之百成功，Guardrails 的目的是降低攻擊成功的機率與成功後能造成的影響，因為 LLM 的輸出具有不確定性，新的 Jailbreak、Prompt Injection 技巧也可能持續出現，假設其中一道防禦可能失敗，下一道防禦能不能把攻擊擋下來？這也是 AI Security 很重要的 Defense in Depth 思維，簡單來說我們不假設單一防線是絕對安全的，而是預設任何防線都有可能被突破，不全信任 AI，建立起有規則與約束力的牆，讓系統更加不容易被攻擊。

Guardrails 不是一個工具

Guardrails 並不是某一套特定軟體，而是一種安全設計概念，實際上可以透過很多方式建立 Guardrails，例如：

Input Validation
Output Filtering
Content Moderation
Access Control
Least Privilege
Human Approval

也有專門協助建立 Guardrails 的 Framework，例如 NVIDIA NeMo Guardrails、Guardrails AI 等，接下來幾天，我們也會開始實際使用一些工具與程式碼，看看這些防禦到底怎麼實作。

今天先了解了 Guardrails 的整體概念，接下來我們就開始把這些防線拆開，並加入一些實際工具與 Code，看看 AI Security 在 Application 中到底可以怎麼實作，第一道防線就從使用者送進來的內容開始。

Day 16｜Input Validation：送進 AI 的內容，可以先檢查嗎？